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Description 

[0001] The present invention relates to electronic 
monetary systems in general, and in particular to meas- 
ures for making their use easier for an average user. 
[0002] A conventional Internet Service Provider (ISP) 
system is shown in Figure 1. The basic duty of an ISP 
is to transfer data from one network such as the Internet 
to another network such as the conventional telephone 
network, and vice versa. A user can connect to the In- 
ternet network 116 using his computer 100 and modem 
102 via the conventional telephone network, represent- 
ed in Figure 1 by the user's local telephone exchange 
104, and via the ISP system 105. A conventional ISP 
system 105 comprises a Call Control Point 106, which 
receives the calls and directs them to terminal servers 
1 1 2. The terminal servers 1 1 2 basically convert the data 
signals from the form used in the conventional tele- 
phone network to the form used in the network 116 to 
which the ISP system 1 05 is connected to, and vice ver- 
sa. Atypical ISP system 105 further comprises a router 
1 1 4, which receives the data signals from terminal serv- 
ers 112 and sends them to the network 116, and con- 
versely, receives data signals from the network 116, and 
based on the destination addresses given in the data 
signals, forwards each signal to the correct terminal 
server 112. A typical ISP system 105 also comprises a 
proxy 118, which functions as an intermediary between 
the users of the ISP and third parties in the network 116. 
A proxy typically caches in its mass memory most recent 
documents, which the users of the ISP retrieve from the 
network. If a user transmits a request for a document 
which had recently been accessed from the ISP and is 
therefore cached in the memory of the proxy, the proxy 
sends the user a copy of the document from its memory, 
in order to reduce the load on the network 1 1 6 and speed 
up the service perceived by the user. 
[0003] The data signals are transferred in the Internet 
with TCP/IP protocol, which is described in detail in the 
standards RFC 791 and RFC 793. World Wide Web 
(WWW) documents can be accessed on WWW servers 
in the Internet with the help of the HTTP protocol, which 
defines among others, a standard format for requesting 
a certain document on a given WWW server. Version 
1 .0 of the HTTP protocol is defined in the standard RFC 
1945. The TCP/IP protocol and the HTTP protocol are 
both well known to the man skilled in the art, and do not 
require further elaboration. 

[0004] Figure 2 shows the configuration of a second 
type of telephone network service, namely a voice serv- 
ice provider system 210 used for example in automated 
ordering services. Figure 2 shows an example, how an 
Intelligent Network (IN) compliant telephone exchange 
can be used to produce an automated service. The 
voice service system 210 comprises an IN-compliant 
Service Switching Point (SSP) 104, a Service Control 
Point (SCP) 110 which controls the SSP, and a database 
with voice output 212. The dun of the SSP is basically 



to connect the callers to the outputs of the database 21 2. 
The user can, for example, order tickets from such a 
service by pressing the number keys on his telephone, 
while the SCP guides the user with the help of the mes- 

5 sages in the database 21 2. Intelligent Network features 
and the capabilities of various IN components, such as 
the CCP, SCP and SSP are described in several CCITT 
recommendations, for example the recommendations 
Q.1201, Q.1202, Q.1203, Q.1204, Q.1205, Q.1211, Q. 

io 1213, Q.1214, Q.1215, and Q.1218. 

[0005] Several versions of electronic money are avail- 
able or under development today. An overview of major 
versions of electronic money is given in the cover story 
and related articles in the June 1996 issue of the Byte 

is magazine. In one system, a user can obtain electronic 
cash from a provider of electronic cash, which gives the 
user electronic symbols representing the amount of 
money paid by the user. The user typically stores these 
symbols in his computer with the help of a electronic wal- 

20 let program, and uses the symbols later for payment of 
various services or merchandise over a telecommuni- 
cations network, such as the Internet. After the transac- 
tion, the merchant can send the received symbols to the 
provider of electronic cash and change them to real 

25 money. Such an electronic monetary system is de- 
scribed in detail in, for example, the European patent 
application EP 542 298 and the references contained 
therein. An electronic monetary system based on the 
use of credit cards or like means of payment is currently 

30 being developed by major credit card companies. One 
similar credit card based system is described in the 
standard RFC 1898. 

[0006] Common to all current electronic monetary 
systems is that they are cumbersome from the user's 

35 point of the view. The user must first obtain the electronic 
money before being able to pay for services or merchan- 
dise over a communications network such as the Inter- 
net. Further, the usertypically needs a special electronic 
wallet program. In one major credit card based electron- 

40 ic monetary system, the user must obtain an electronic 
identification certificate identifying him as the rightful 
owner and user of his credit card. 
[0007] These requirements cause a burden on the us- 
er, and requires the average user to know about the de- 

45 tails of various forms of electronic money and learn how 
to obtain and use such electronic money. The symbols 
representing the electronic money are typically stored 
on the hard disk of the user's computer, and are vulner- 
able to accidental erasure or malfunction of the hard 

50 disk. Therefore, the user should take good care of the 
electronic cash, and take backup copies of the symbols 
representing the money. Although electronic monetary 
systems provide for replacement of accidentally lost 
electronic money, the replacement procedure is a bur- 

55 den on the user. Further, since there are more than one 
type of electronic money being developed, the user 
needs to obtain all major types of electronic money if he 
desires not to be limited in his buying choices, since it 
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is very probable that all merchants will not accept all 
forms of electronic money. 

[0008] An object of the invention is to make it easy for 
a user to pay with electronic money. A further object of 
the invention is to allow a user to pay with electronic 
money without requiring him to obtain any electronic 
money himself. The object is solved by the features of 
the independent claims. The system according to the 
invention comprises the features of claim 1 . The method 
according to the invention comprises the features of 
claim 12. A still further object is to implement a system, 
with which Internet Service Providers and like services 
can provide an easy way of using electronic money for 
their users. 

[0009] These aims will be reached by adding an inter- 
cepting means and electronic wallet means to an ISP 
system, and arranging the system to 

optionally initiate the payment procedure on the re- 
quest of the user, 

intercept and redirect to the electron ic wallet means 
an incoming payment request addressed to a user, 
add a charge corresponding to the requested 
amount to the user's telephone bill, and 
send from the electronic wallet means an electronic 
money payment in response to the payment request 
from a merchant. 

[0010] The present invention is based on the idea, 
that the use of electronic money is greatly simplified for 
a non -expert user, if the ISP takes care of the electronic 
money payments, and adds corresponding charges on 
the user's telephone bill or uses some other suitable way 
of obtaining a payment from the user. Such functionality 
requires the intervention of the ISP in the transmissions 
between a user and a third party, i.e. intercepting the 
electronic payment requests sent by a merchant. Ac- 
cording to a preferable embodiment of the present in- 
vention, the ISP uses electronic money on behalf of the 
user, and charges the payments on the user's telephone 
bill. The ISP can take care of all technical details nec- 
essary for obtaining different forms of electronic money 
in a centralized manner, and all users of the ISP can use 
the electronic money obtained by the ISP simply by al- 
lowing the ISP to add corresponding charges to their tel- 
ephone bills. Further, the ISP can obtain all major forms 
of electronic money, whereafter a user can choose the 
most economical way of payment, if a merchant accepts 
payments in more than one form of electronic money. 
[0011] The system comprises an interception means, 
which examines the incoming data traffic. When the in- 
terception means notices that a transmission contains 
a request for payment with electronic money, it redirects 
the transmission to another means comprising the func- 
tionality necessary for the use of electronic money. After 
this, the system inspects the request, adds a corre- 
sponding amount to the user's telephone bill and con- 
tinues with the payment according to the received re- 



quest. The system can further comprise means for con- 
trolling, and optionally initiating, the payments. For ex- 
ample, the user can set up an acceptance policy or ac- 
cept or reject individual payments through a separate 
5 connection to a network address administered by the 
system. 

[0012] Various embodiments of the invention will be 
described in detail below, by way of example only, with 
reference to the accompanying drawings, of which 

10 

Figure 1 shows, how a user can connect to a net- 
work such as the Internet according to the 
prior art, 

is Figure 2 shows an example of a voice service pro- 
vider system using an I N-com pliant tele- 
phone exchange, 

Figure 3 shows a basic example of a system ac- 
20 cording to the invention, 

Figure 4 shows another example of a system ac- 
cording to the invention, 

2S Figure 5 shows an embodiment of the invention, in 
which the interception means 1 20 outputs 
the redirected traffic via the same output 
as the rest of the traffic, 

30 Figure 6 shows an example, where the system ac- 
cording to the invention is implemented in 
a system connected to a mobile telephone 
network, 

35 Figure 7 shows an advantageous embodiment of 
the invention, where the interception 
means 1 20 is implemented within a proxy 
118, and 

40 Figure 8 shows an example of a particular imple- 
mentation of the system according to the 
invention. 

[0013] Figures 1 and 2 were described earlier in con- 
45 nection with the description of the state of the art. 

[0014] Figure 3 shows a basic example of an advan- 
tageous embodiment of the invention. !n this example, 
the user is in contact with a merchant 1 30 with his com- 
puter 1 00 and modem 1 02 or ISDN adapter 1 03, through 
so the local telephone exchange 104, the system 105 of 
the Internet service provider (ISP), and the network 1 1 6. 
In the system according to the invention, the ISP system 
105 additionally comprises an intercepting means 120. 
The intercepting means 120 redirects the payment re- 
55 quests originating from the network to the control unit 
122 of the ISP system 105. When the user gives a re- 
quest for a service or a merchandise, the merchant's 
1 30 system responds with a payment request. The in- 
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tercepting means 120 redirects the request to the con- 
trol unit 122, which sends conventional accounting sig- 
nals corresponding to the payment via the SSP 106 to 
the user's local telephone exchange 1 04, where the cor- 
responding sum is added to the user's telephone bill, s 
After sending the accounting signals, the control unit 
1 22 sends the electronic money to the merchant 1 30 via 
the network 116. After receiving the electronic money, 
the merchant 1 30 continues with producing the request- 
ed service or merchandise. 10 
[0015] The control unit may send the electronic mon- 
ey and other messages to the merchant via the inter- 
cepting means 120 as in the embodiment of Figure 3, 
or past the intercepting means, for example via a router 
included in the ISP system. is 
[0016] The control unit may effect the debiting of the 
user's telephone account at any convenient stage in the 
payment procedure, not only in the beginning of the pro- 
cedure. Naturally, it may be desirable for the ISP to ef- 
fect the debiting at the latest before a point in the pay- 20 
ment procedure after which the payment cannot be can- 
celled, if the debiting for some reason is not succesful. 
[0017] In one advantageous embodiment of the in- 
vention, the control unit 1 22 comprises in addition to the 
functionality needed for the use of electronic money, al- 25 
so the functionality of a conventional I N-compliant Serv- 
ice Control Point. 

[0018] In the embodiment of Figure 3, the electronic 
wallet means, i.e. the electronic money transaction 
means, is located in the control unit 1 22 or a similar tunc- 30 
tional entity The wallet and its contents are taken care 
of by the ISP, which obtains more electronic money from 
a electronic money provider when necessary. The ISP 
can obtain all major forms of electronic money from ma- 
jor electronic money providers, whereafter the user 35 
does not need to take notice of which merchants require 
which kind of electronic money. 

[0019] One important aspect of electronic, money is 
the possibility for the user to accept or reject any given 
payment request. In the system according to invention, 40 
this can be implemented in several ways. One advanta- 
geous embodiment is shown in Fig. 4. The control unit 
122 is connected to the router 114, and the user can 
form a connection to a payment control means 122a in 
the control unit 122. This payment control means 122a 4$ 
can be, for example, in the form of a World Wide Web 
(WWW) document at a certain network address, which 
is administered by the control unit 122. The router 114 
directs all communication from the user to this network 
address directly to the control unit. The user can open so 
a connection to the network address of said payment 
control means in the same conventional way as to any 
other address in the network 116. The control unit 122 
can recognize the user connecting to it via the network 
1 1 6 based on the user's network address, since the con- ss 
trol unit 1 22 knows the network addresses allocated for 
the users of the ISP system 105. Once the user has 
opened a connection to the said network address of the 



control unit 122, the control unit 122 can inform the user 
via the opened connection of an eventual incoming pay- 
ment request and ask for confirmation. 
[0020] The payment control means and other control 
means described later in this application could be direct- 
ly connected to the network 116. In that case, commu- 
nication from the user to the control means would pass 
through at least a part of the network 116. However, 
such a configuration would be more vulnerable to out- 
side attacks, since the important information determin- 
ing the acceptance of payments would briefly flow out- 
side the ISP system. The configuration shown in Figure 
4 is more secure, since the communication between the 
user and the control means only takes place within the 
conventional telephone network and within the ISP sys- 
tem. 

[0021] As in the case of conventional electronic mon- 
ey, the user can adopt a default policy towards payment 
requests and instruct the ISP to treat incoming payment 
requests accordingly. The policy can include, for exam- 
ple, the options of 

allowing payments under a certain limit, 
allowing all payments until a certain cumulative 
amount has been reached in a given time period, 
allowing all payments to a given merchant or a 
number of merchants, 

forbidding all payments to a given merchant or a 
number of merchants, 
any combinations of the previous, or 
forbidding all payments. 

[0022] The user can set up the policy with the ISP in 
many ways, for example, by making a separate agree- 
ment with the ISP. The ISP can as well set up a default 
policy, which the users agree on when starting to use 
the services of the ISP. In one advantageous embodi- 
ment of the invention, the control unit 1 22 comprises pol- 
icy control means 122b, and the user can control and 
adjust the payment acceptancy policy by connecting to 
the control unit 122 through the network as described 
above, and instructing the control unit 122 with the help 
of the said policy control means 122b. The control unit 
122 can find out which user's policy information to 
change by recognizing the user in the way described 
previously 

[0023] A further aspect of electronic money, namely 
the voluntary sending of an amount of electronic money, 
can be implemented in a similar way In one advanta- 
geous embodiment of the invention, the control unit 1 22 
comprises payment sending means 122c, which the us- 
er can connect to at a certain network address as de- 
scribed previously. After connecting to the said payment 
sending means 122c p the user can instruct the payment 
sending means 122c to send an electronic payment to 
a desired network address. After receiving the instruc- 
tion to send a payment, the payment sending means 
preferably first sends accounting signals to the user's 
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exchange 1 04 to add the amount to be sent to the user's 
telephone bill, after which the payment sending means 
122c sends the instructed amount of electronic money 
to the desired address, indicating the user as the sender 
of the money. It is also possible that a user wishes to 
send an anonymous donation. Therefore, the payment 
sending means 122c preferably also comprises a con- 
trol means allowing the user to instruct the payment 
sending means 1 22c not to designate him nor any other 
person as the sender of the payment. The user may also 
use any of the known methods of hiding the identity of 
the sender of a message, for example by sending the 
payment via a special anonymous server. 
[0024] In some electronic money systems the user 
may need to initiate a payment procedure himself. In the 
system the user can initiate the payment for example 
with the payment sending means 1 22c or other similar 
control means. 

[0025] In one advantageous embodiment of the in- 
vention, the payment control means 1 22a, policy control 
means 122b, payment sending means 122c, and any 
other control means described in this application are 
combined into one general control means, in order to 
allow the user to control all aspects of the electronic 
money with a single connection. Also any combinations 
of the control unit 1 22 and any control means described 
in this application are possible to implement. 
[0026] In a further advantageous embodiment of the 
invention, the system according to the invention pro- 
vides for a further aspect of electronic monetary sys- 
tems, namely receiving payments. In this embodiment, 
the system according to the invention receives and proc- 
esses the payment in the way specified by the electronic 
monetary system in question. After receiving the pay- 
ment, the system transfers a corresponding amount of 
credit to the user. The transferring may proceed, for ex- 
ample, in one of the following ways: 

if the base network through which the user is con- 
nected to the ISP allows crediting the user's ac- 
count, the system can credit that account; 
the ISP can keep internal accounts for the users, in 
which case the payment is added to the account; or 
the ISP can initiate an automatic bank transfer to 
the bank account of the user, if the user has in- 
formed the ISP of his bank and his bank account. 

Alternatively, the system according to the invention can 
employ any of the prior art methods of crediting an ac- 
count, used for example in conjunction with various 
service lines charging an extra fee above the normal call 
fee. Preferably, the system according to the invention 
can be instructed by a user to collect payments into an 
internal account until a specified minimum amount has 
been reached, before transferring the accumulated 
credit to the user. 

[0027] The control unit 122 can include details about 
each payment in the accounting information sent to the 



user's telephone exchange 104 to allow detailed itemi- 
zation of paid goods and services on the user's tele- 
phone bill, if the base network containing the telephone 
exchange 104 supports detailed itemization of the tele- 
s phone bill. This kind of reporting may also be accom- 
plished through sending a separate information letter or 
e-mail to the user or using any other known means of 
informing a user. 

[0028] The requested payments might not be exact 
multiples of the charging unit of the telephone network, 
through which the user is connected to the ISP system 
105. The requested payments may even be substantial- 
ly smaller than conventional charging units, since many 
electronic monetary systems provide for very small pay- 
ments called micropayments. The system according to 
the invention may comprise means for keeping ac- 
counts for sums below one charging unit, and wait until 
the total of payments exceeds one charging unit, before 
sending accounting signals to the user's local exchange 
for adding one charging unit to the user's telephone bill. 
The invention does not limit the charging practices of 
the ISP system in any way. The ISP can for example 
add a surcharge for every electronic payment made us- 
ing the system according to the invention. 
[0029] In one advantageous embodiment of the in- 
vention, the ISP sends the user a separate invoice, in- 
stead of charging his telephone account. The ISP may 
collect a number of payments into an internal account, 
until a first predetermined sum has been reached, after 
which the ISP sends an invoice. If a payment is larger 
than a second predetermined sum, the ISP can send an 
invoice covering that particular payment. The ISP may 
as well require the user to deposit an amount before al- 
lowing the user to use the electronic money of the ISP, 
i.e. require payment before use. Naturally, any conven- 
tional invoicing methods may be used. 
[0030] The system according to invention can use any 
electronic monetary system, even credit card based 
monetary systems. The system can pay the merchant 
with the credit cards issued to the ISP, after adding the 
corresponding sum to the user's telephone bill. The ISP 
can obtain all necessary electronic identification certifi- 
cates and programs necessary for using a given type of 
credit card based electronic money, thus alleviating the 
burden from the users of the ISP. 
[0031] The basic functions performed by the inter- 
cepting means 120 include, but are not limited to, the 
following: 

the intercepting means 120 inspects every incom- 
ing data packet, 

if the data packet does not contain electronic money 
traffic, the data packet is forwarded in the normal 
way to the user, 

if the data packet does contain electronic money 
traffic, the intercepting means 120 directs it to the 
electronic money transaction means. 
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[0032] The method of detecting electronic money traf- 
fic from other traffic may vary depending on the actual 
protocol used to transfer money. In the current electronic 
monetary systems the two main approaches for the 
transmission of electronic money information are the fol- 
lowing: 

1 ) the electronic money traffic is directed to a certain 
port according to the TCP/IP-protocol, 

2) the electronic money information is contained 
within special fields of the HTTP protocol. 

Preferably, the system according to the invention is ar- 
ranged to handle both types of electronic money infor- 
mation. For clarity, the cases 1) and 2) are discussed 
separately in the following paragraphs. 
[0033] In the case that the electronic money traffic is 
directed to a certain TCP port, the basic function of the 
intercepting means 120 of redirecting electronic money 
traffic to the control unit 1 22 can be implemented in sev- 
eral ways, which include at least the following: 

1a) The intercepting means 120 can redirect the 
electronic money containing packets to a different 
output than the rest of the traffic, as shown in Fig. 4. 
1b) The intercepting means 120 can treat a packet 
containing electronic money as a piece of data and 
pack it into one or more IP packets addressed to 
the control unit 122 and forward the new packets to 
the same output as the rest of the traffic, after which 
the router 114 of the ISP system 105 switches the 
new packets to the control unit 122. 
1c) The intercepting means 120 can rewrite the 
packet, replacing the user's address with the ad- 
dress of the control unit 122 in the destination ad- 
dress field of the packet, and encoding the user's 
address in other fields of the packet or by adding a 
source routing option to allow the control unit 1 22 
to recognize which user the packet was originally 
addressed to. After rewriting, the intercepting 
means 120 forwards the the rewritten packet to the 
same output as the rest of the traffic, whereafter the 
router 114 of the ISP system 105 switches the new 
packets to the control unit 122. 

[0034] The configuration of the embodiment shown in 
Figure 5 is suitable for use with the said ways of imple- 
mentation 1b) and 1c). In this embodiment, the inter- 
cepting means 120 effects the redirection of the packets 
by readdressing them to the control unit 1 22. The router 
114 subsequently forwards all packets to their stated 
destination addresses, whereafter the redirected pack- 
ets reach the control unit 1 22. 

[0035] The exact TCP port dedicated for electronic 
money traffic may vary depending on the electronic 
money provider. In this case, the intercepting means 
1 20 can check, if the TCP port number in the destination 
port field of the packet corresponds to any of the port 



numbers in a predetermined set of port numbers. 
[0036] In one advantageous embodiment of the in- 
vention, the intercepting means 120 redirects the elec- 
tronic money traffic addressed to only some users, and 

5 passes through the electronic money traffic addressed 
to other users without redirection. In this embodiment, 
if the data packet contains electronic money traffic, the 
intercepting means 120 determines the destination of 
the packet. If the packet destination is not one of the 

10 users in a certain category, the packet is passed nor- 
mally to the end user. In this embodiment, the users of 
the ISP can take care of the electronic money them- 
selves in the manner known in the art, if they do not wish 
to pay for any services or merchanise on the telephone 

15 bill. Such an option would be useful, for instance, for the 
employees of a small company, who are using the com- 
pany's account at the ISP to access the network, and 
who wish to pay themselves for the services or mer- 
chandise. The intercepting means can also redirect pay- 

20 ment requests of certain kinds of electronic money only, 
and pass payment requests of other kinds of electronic 
money without redirection. These features can be pref- 
erably controlled by a control means similar to previous- 
ly described control means 122a, 122b, and 122c. 

25 [0037] The case 2) above, i.e. when the electronic 
money information is contained within additional fields 
of a HTTP request according to the HTTP protocol, is 
slightly more complicated. A HTTP request may be sent 
over a network in one or more transmission units such 

30 as TCP packets, depending on the size of the request 
and the size of a single transmission unit of the network. 
Therefore, the HTTP request may need to be recon- 
structed from the sent transmission units, before the in- 
tercepting means 120 can inspect, whether the request 

35 contains electronic money information or not. 

[0038] The HTTP protocol allows for transmission 
various data fields before payload data in a single trans- 
mission such as a HTTP request. The HTTP protocol 
itself defines and uses some fields, and electronic mon- 

40 etary systems may define other fields. 

[0039] The electronic monetary systems may use at 
least the following formats in a single HTTP transmis- 
sion: 

45 2a) the transmission only contains the electronic 
money information in one or more fields, 
2b) the transmission contains the electronic money 
information in one or more fields and as the payload 
data of the transmission, or 
50 2b) the transmission contains the electronic money 
information in one or more fields, and a document. 

[0040] In the cases 2a) and 2b) above, the transmis- 
sion only contains electronic money information in var- 
55 ious forms. In these cases, the intercepting means 120 
redirects the transmission to the control unit 122, which 
can subsequently act as required by the electronic pay- 
ment protocol in question and as described above in 
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connection with the description of Figure 3. 
[0041] The case 2c) above is more complicated. As 
above, the intercepting means 120 redirects the trans- 
mission to the control unit 122. In this case the control 
unit 1 22 must decide, whether the user needs to receive 
the document contained as the paybad data of the 
transmission. If the control unit 122 is able to determine 
that the user does not need to receive the document, 
the system can act as described above at points 2a) and 
2b). This determination is possible, if the electronic pay- 
ment protocol in question has standardized the content 
of such a document, and the control unit 1 22 can verify 
that the document does not contain any new information 
for the user. For example, it may be a HTML document 
of a predetermined structure, containing a question 
about acceptance of the purchase and the definitions of 
a "Yes" and a "Cancel" button for the user to approve or 
to cancel the purchase. If the purchase is within the lim- 
its indicated by the user for automatic acceptance, the 
control unit 122 does not need to present the question 
to the user. 

[0042] If the control unit 122 is unable to determine 
that the user does not need to receive the document, it 
must pass the HTTP request containing the document 
to the user. The control unit can accomplish this for ex- 
ample by sending the HTTP request back to the inter- 
cepting means 120, instructing the intercepting means 
1 20 to send the HTTP request to the user. Alternatively, 
the system may comprise another means for adding 
such requests sent by the control unit to the data com- 
munication traffic directed to the user. In order not to in- 
voke a payment procedure at the user's computer, the 
control unit 1 22 preferably removes the fields containing 
electronic money information from the HTTP request 
forwarded to the user or replaces them or their contents 
with an indication to the effect that the payment is al- 
ready being taken care of. 

[0043] In a further advantageous embodiment of the 
invention, the system according to the invention can 
prompt the user for the acceptance or denial of a pay- 
ment by sending the user an electronic document, such 
as a HTML document, containing for example a ques- 
tion about acceptance of the purchase and the defini- 
tions of a "Yes" and a "Cancel" button for the user to 
approve or to cancel the purchase. Specifically, in the 
case 2c) described above, the control unit can replace 
the document sent by the merchant with a similar doc- 
ument specific of the ISP system before forwarding the 
HTTP request to the user. Of course, as described 
above, the control unit needs to determine first, if it is 
allowed to replace the original document. 
[0044] The HTTP 1 .0 protocol is defined in the stand- 
ard RFC 1945 and is well known by the man skilled in 
the art. Therefore, the protocol is not described in this 
application. The exact fields and field names utilized by 
various electronic monetary systems may vary accord- 
ing to monetary system and electronic money provider 
in question, wherefore the exact fields and field names 



are not defined in this application. The system according 
to the invention can be arranged to act upon any given 
protocol for transmission of electronic payments. 
[0045] In a further advantageous embodiment of the 
5 invention, the intercepting means 1 20 redirects all HTTP 
traffic on the basis of the TCP port number reserved for 
the HTTP protocol. The system according to the inven- 
tion can employ a two-level intercepting means scheme, 
in which the redirected HTTP traffic is interpreted and 
inspected by a second-level intercepting means, which 
directs HTTP transmissions containing electronic mon- 
ey information to the control unit 122, and forwards the 
rest of the HTTP traffic to the user. Alternatively, the first 
intercepting means 120 can redirect all HTTP traffic di- 
rectly to the control unit 122, which then interprets and 
inspects all HTTP transmissions. As previously, if any 
given HTTP transmission does not contain electronic 
money information, the transmission is forwarded to the 
user. If a HTTP transmission contains electronic money 
information, the transmission can be handled as de- 
scribed previously. 

[0046] In a further advantageous embodiment shown 
in Figure 7, the intercepting means 1 20 and preferably 
also the functionality of the control unit 122 pertaining 
to electronic money are implemented in the proxy 118 
of the ISP system. For example, the electronic wallet 
means 124 of the ISP system could be implemented in 
the proxy 118 instead of the control unit 122, as de- 
scribed previously. Also, the control means 122a, 122b 
and 122c and other control means pertaining to use of 
electronic money can be controlled by the proxy 118, in 
the embodiment of Figure 7. In this embodiment, the re- 
maining functionality of the control unit 1 22 is very close 
to that of a conventional Service Control Point 11 0 of an 
IN-compliant telephone exchange. The proxy 118 can 
handle all details of the electronic money transactions, 
and the control unit 122 in addition to the conventional 
functions of a Service Control Point, only needs to be 
able to receive accounting information from the proxy 
118 and return a confirmation of a succesful addition of 
a sum on the user's telephone bill. 
[0047] In conventional ISP systems, the use of the 
system's proxy is not mandatory for a user, and he can 
configure the programs in his computer not to use the 
proxy. In the embodiment of Figure 7, the user can con- 
trol the usage of electronic money also by choosing 
whether to use the proxy 1 1 8 or not. Further, a large I SP 
may have more than one proxy to handle the traffic; in 
that case, the user may choose which proxy to use: one 
with electronic money functionality, or a conventional 
one without functionality supporting the use of electronic 
money. In the embodiment of Figure 7, if the user does 
not use a proxy or uses a conventional proxy, the ISP 
does not treat the electronic money traffic for that user 
in any special way, whereafter the user may use his own 
electronic money if he so wishes. 
[0048] The intercepting means 1 20 can also be imple- 
mented, for example, in a firewall device. A firewall de- 
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vice is typically a computer running screening software, 
installed between a system and a network to protect the 
system from unwanted intruders from the network. One 
typical way of operation for a firewall device is to read- 
dress all traffic originating from users of the system and 
all incoming traffic addressed to users in the system, in 
order not to reveal the true network addresses of the 
users. That is, in outgoing traffic the firewall replaces the 
user's address with a bogus address and stores the us- 
er's address and the bogus address in its memory. Con- 
versely, the firewall device replaces the bogus address 
given as the destination address in an incoming mes- 
sage with the real address of the user. The firewall usu- 
ally blocks all incoming traffic addressed to any other 
addresses. Such a readdressing means provides an ad- 
vantageous starting point for implementation of an in- 
tercepting means, which effects the separation of elec- 
tronic money traffic from the rest of the traffic by read- 
dressing the electronic money traffic as described pre- 
viously. 

[0049] The inclusion of the electronic money functions 
in the control unit 122 in some of the previously de- 
scribed embodiments of the invention was presented as 
an example only. The separation of the electronic mon- 
ey functions from the control unit 122 to a separate 
means such as a proxy 118 as in the previous example, 
or a separate electronic money unit can be incorporated 
in any of the embodiments described in this application. 
[0050] In a further advantageous embodiment, the 
system according to the invention can convert one form 
of electronic money to other forms of electronic money. 
For example, the user may have only one type of elec- 
tronic money, in which case it is desirable that the ISP 
system would convert requests for payment into re- 
quests of that type of electronic money, with which the 
user can pay. In such an embodiment, the system ac- 
cording to the invention sends the user a conventional 
payment request, instead of sending accounting infor- 
mation to the conventional telephone network to charge 
his telephone bill. After receiving the payment from the 
user, the ISP system can respond to the original pay- 
ment request in whatever type of electronic money re- 
quested. 

[0051] The system can further be used to make it eas- 
ier to obtain electronic money. If a user wishes to obtain 
electronic money to be able to make electronic pay- 
ments independently of the ISP, he can contact a bank 
which has made a special agreement with the ISP al- 
lowing the ISP's users to download electronic money in- 
to their own computers from the bank and to pay for the 
downloaded money along with their telephone bill. Al- 
ternatively, since a bank can act as a conventional mer- 
chant as well, the user can contact a bank which sells 
electronic money, i.e. changes one type of electronic 
money to other types of electronic money for a commis- 
sion. This way, a user can obtain electronic money into 
his computer, which he can then use in other systems 
without the help of the ISP. For example, the user can 



download the electronic money from his computer into 
a smart card, and pay with the smart card for purchases 
in conventional shops, for tickets on the city transport 
etc. 

5 [0052] In the previous embodiments, the network 116 
can be, but is not limited to, the Internet. The network 
116 may be any other network, for example a closed 
networkof a certain business sector, closed in the sense 
that it is only accessible to companies, not individual 

10 persons. 

[0053] In the previous embodiments, the user was 
connected to the ISP system 105 via a conventional 
PSTN/ISDN telephone network. However, the system 
according to the invention can be used in conjunction 

is with other types of telecommunications networks as 
well. In one advantageous embodiment of the invention, 
the user is connected to the ISP system 1 05 via a mobile 
telecommunications network 200, as shown in Figure 6. 
For example, the user can contact the ISP system 105 

20 with his laptop computer 100 and mobile telephone 202, 
via the base station 204 of the mobile telecommunica- 
tions network 200. The mobile telecommunications net- 
work 200 can be for example a GSM (Global System for 
Mobile communications) or a DAMPS (Digital Advanced 

25 Mobile Phone Service) network. Alternatively, the user 
can use a PDA device 206 (Personal Digital Assistant) 
comprising mobile terminal functions, or a similar device 
to connect to the ISP via the mobile network 200. The 
embodiment shown in Figure 6 is very advantageous for 

30 those mobile telephone service providers which also sell 
ISP services. Other possible telecommunication net- 
works are cable television networks, where several sug- 
gestions have been made which would convert the ca- 
ble TV network from a one-way broadcasting network 

35 into a two-way telecommunications network. 

[0054] The previous embodiments describe several 
functional entities, such as the intercepting means 120, 
the control unit 122, and the electronic wallet means 
124. These functional entities can be implemented in 

40 many different ways in one or more physical pieces of 
equipment, and the invention does not limit the form of 
implementation of these entities. For example, the inter- 
cepting means 120 can be implemented in the router 
114, or a plurality of intercepting means 120 can be im- 

45 plemented in the terminal servers 1 1 2. The intercepting 
means 120 and the control unit 122 can even be imple- 
mented in the same physical device. Further, if desired, 
the control unit 122 can be implemented with several 
sub-units in one or more physically separate devices. 

50 For example, the functionality of the control unit 1 22 can 
be implemented as computer programs functioning in 
one or more computers. 

[0055] In the following paragraphs, a description of 
one exemplary embodiment of the invention is present- 
55 ed with reference to Figure 8. 

[0056] In this embodiment, the intercepting means 
120 is implemented in a fast microcomputer running the 
NetBSD operating system. The microcomputer is 
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equipped with local area network (LAN) interfaces for 
connection to the Internet, to the terminal servers 112 
and to the control unit 112. The TCP level intercepting 
means is implemented by changing the operating sys- 
tem kernel routines handling IP packets. Namely, the 5 
ip_input() operating system function is modified to in- 
spect all incoming TCP/IP packets. Those packets that 
include electronic money information, i.e. designate a 
port number reserved for an electronic monetary sys- 
tem, are redirected to the control unit 122 via the LAN 
interface. Packets containing HTTP traffic are directed 
to HTTP screening software 120' running in the same 
microcomputer. 

[0057] The HTTP screening and intercepting software 
1 20', which was in the description of one of the previous 
embodiments referenced to as a second-level intercept- 
ing means, receives all packets containing HTTP traffic 
from the modified operating system kernel. The HTTP 
screening and intercepting software 120' inspects the 
packets to determine, whether the packets contain elec- 
tronic money information. If this cannot be determined 
from a single packet in the case of a HTTP transmission 
consisting of more than one packet, the HTTP screening 
and intercepting software 120' can collect several pack- 
ets before making the determination. If a HTTP trans- 
mission does not contain electronic money information, 
the transmission is forwarded to the terminal server 1 1 2. 
HTTP transmissions containing electronic money infor- 
mation are forwarded to the control unit 122. 
[0058] The microcomputer is also equipped with rout- 
er software to route the non- redirected traffic to the ter- 
minal servers and traffic originating from the user to the 
Internet and to the control means implemented by the 
transaction authorization means 122e. 
[0059] In the embodiment of Figure 8, the control unit 
1 22 comprises a Unix server, such as a HP 700 series 
workstation. The workstation runs the electronic wallet 
software 124, transaction authorization software 122e, 
SCP software 122h, user authentication software 122f 
and call database software 1 22g. 
[0060] The electronic wallet software 124 comprises 
functions enabling the software to act as a client, i.e. 
buyer, in electronic money transactions. The wallet soft- 
ware preferably comprises specialized functions for 
handling different forms of electronic money, such as the 
E-cash and the credit card based SET protocol. The 
electronic wallet software handles the electronic money 
transaction messages received from the intercepting 
means 120, 120' and queries the transaction authoriza- 
tion software for acceptance or denial of a transaction. 
After receiving an authorization, the electronic wallet 
software obtains the telephone call identifier from the 
call database software on the basis of the user's IP ad- 
dress specified in the transaction message. After receiv- 
ing the call identifier, the electronic money software in- 
structs the SCP software to debit an amount of money 
on the user's telephone account. The amount to be deb- 
ited is based on the electronic money transaction re- 



quest, possibly including service commissions of the 
ISP, sales taxes and other fees. If the exact amount can- 
not be charged due to fixed size of charging units within 
the telephone network, the excess charge can be stored 
in the call database as temporary user credit, or be re- 
funded by adjusting the basic charging interval within 
the telephone network. When the electronic wallet soft- 
ware receives from the SCP software an indication that 
the amount requested has been charged, it continues 
the electronic money transaction. The electronic wallet 
software includes the user's IP address information in 
such a way in the transmission sent as a reply to the 
merchant, that the user is identified as the sender of the 
transmission. 

[0061] The electronic wallet software 124 preferably 
holds a sufficiently large sum of electronic money, and 
all necessary certificates and credit and debit card num- 
bers necessary for using credit card based electronic 
monetary systems. 

[0062] Transaction authorization software 122e de- 
termines, whether a given transaction is authorized or 
not. The transaction authorization software comprises 
the functions necessary for implementing the authoriza- 
tion policy options described previously in connection 
with description of Figure 3. 

[0063] Preferably, the authorization software 1 22e al- 
so implements the payment control means 122a and 
policy control means 122b described previously. For 
that purpose, the authorization software administers 
one or more WWW documents, in the form of HTML 
forms using CGI scripts. The users can access these 
documents at a special network address, where the us- 
ers can connect to in the same way as they would to any 
network address. The combined intercepting means 
and router 1 20 routes HTTP requests addressed to that 
address and originated by the users of the ISP to the 
authorization software. If a user has opened a connec- 
tion to the special network address and obtained the 
payment control form, the authorization software can in- 
form the user of a new payment request by sending the 
user an update of the form. The authorization software 
can recognize and certify that the intended user con- 
firms the right payment request or that a user changes 
his own payment policy options, by checking the send- 
er's IP address in the HTTP transmission sent by the 
user. 

[0064] The SCP software 122h comprises the func- 
tions needed for an IN-compliant Service Control Point. 
One example of such software is the OSN SCP software 
of Systems Software Partners Ltd., Lappeenranta, Fin- 
land. For the embodiment of Figure 8, software provid- 
ing a standard SCP functionality needs to be augmented 
with functions implementing the ability to communicate 
with the electronic wallet software 1 24. 
[0065] Whenever a new connection is opened 
through the SSP 106, the SCP software 122h stores in- 
formation about the call to the call database 122g. This 
information can comprise a cali identifier for future ac- 
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counting functions and a line identification, that allows 
the user authentication software 122f to assign an IP 
number for that particular call. When a connection is 
closed, the SCP software 122h removes the information 
about the call from the call database 122g. 
[0066] The accounting function of the SCP software 
122h is initiated by the electronic wallet software 124. 
When the SCP software 122h receives an accounting 
request from the electronic wallet software 124 indicat- 
ing the amount of money to be charged and the call iden- 
tifier, the SCP software 1 22h converts the amount into 
charging units of the telephone network, and instructs 
the SSP 106 to perform the actual charging. After the 
SSP indicates that the charging is completed, the SCP 
sends an accounting reply to the electronic wallet soft- 
ware 124, indicating that the accounting function has 
been performed. 

[0067] The user authentication software 1 22f assigns 
an IP number for each incoming call, and stores this 
number along with line information into the call data- 
base. Whenever the terminal server 112 receives a new 
incoming call, it sends an authentication request to the 
user authentication software 112f. This authentication 
request includes a line identifier, allowing the user au- 
thentication software 112f to assign an unique IP 
number to that line. The I P number is sent to the terminal 
server as a reply to the authentication request. The user 
authentication software 112f may also authenticate the 
users, i.e. confirm whether a new call is made by a reg- 
istered user of the ISP or not. 

[0068] In this embodiment, the call database software 
122g maintains a database of at least the following in- 
formation: 

telephone account identifier or a call identifier re- 
quired to perform telephone network billing, 
line identifier that identifies the terminal server used 
by the call as well as the logical line number within 
the terminal server, and 
the IP address assigned for the call. 

Several suitable database software packages are avail- 
able to and known by the man skilled in the art 
[0069] The terminal servers of the embodiment in Fig- 
ure 8 can be, for example, Ascend MAX TNT terminal 
servers from Ascend Communications Inc., US. These 
terminal servers can handle a large number of simulta- 
neous calls and can support both conventional and IS- 
DN telephone lines. Whenever a new phone call arrives 
from the SSP 106, the terminal server 112 queries the 
user authentication software 122f, which returns an IP 
number to be assigned for the call. The terminal server 
also gives the IP numberto the user's computer through 
PPP protocol negotiations, after which the terminal serv- 
er 112 starts to pass the user's TCP/IP traffic, until the 
call is terminated. 

[0070] The SSP 106 in the embodiment of Figure 8 
can be a conventional IN-compliant Service Switching 



Point 

[0071] The networks specified in this application, 
such as the Internet and the conventional telephone net- 
work, are specified as examples only and do not limit 
s the invention in any way. The invention can be used in 
any environment comprising a base network with an ac- 
counting function, and services or some forms of mer- 
chandise payable with electronic money. 
[0072] In the previous embodiments, the ISP was giv- 
10 en as an example of a suitable provider of the service 
enabled by the present invention. However, the inven- 
tion is not limited to use by Internet Service Providers. 
For example, a company having an own telephone ex- 
change may provide the system according to the inven- 
tion for the benefit of its employees or its various units, 
without the company being an ISP per se. 
[0073] Using the present invention, a user does not 
need to make separate agreements with electronic 
money providers, nor does the user need to obtain the 
electronic money before its use. The present invention 
alleviates the burden on the user by removing the need 
to learn how to obtain and use electronic money. A user 
does not need to obtain any special electronic money 
software in order to use electronic money. The user 
does not need any extra programs to use the invention, 
other than those needed to use the Internet or similar 
networks in the first place. The invention also removes 
the computational load placed on the user's computer 
by conventional electronic monetary system, since in 
the system according to the invention, computationally 
intensive operations of crypt ing electronic money infor- 
mation are performed in the computers of the ISP. The 
removal of the computational load is especially benefi- 
cial for the users of small PDA-type communication de- 
vices, whose computational capacity is often rather lim- 
ited. 

[0074] The present invention can be used with essen- 
tially all electronic monetary systems. An ISP can obtain 
all major forms of electronic money, whereafter the us- 
ers of the ISP have several different forms of electronic 
money at their easy disposal, resulting in a greater free- 
dom of choice in their merchant selections and purchase 
decisions. Also, users can then choose the most cost 
effective way of payment, since different fees charged 
by electronic money providers may vary according to the 
form of electronic money and the particular electronic 
money provider. 

[0075] In this application, the term conventional trans- 
action means any conventional way of effecting a mon- 
etary transaction, for example such as adding debit or 
credit on a user's telephone account, sending a sepa- 
rate invoice, transferring funds by bank transfer, or 
changing the balance on the user's internal account at 
the ISP for later invoicing or crediting. 
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Claims 

1 . An electronic payment transaction system in a node 
joining a first telecommunications network and a 
second telecommunications network character-, 
ized in that the system comprises an electronic pay- 
ment intercepting means (120), which is arranged 
to redirect at least a part of electronic money trans- 
action messages arriving from the first telecommu- 
nications network and addressed to users in the 
second telecommunications network to an electron- 
ic wallet means (124), which electronic wallet 
means (124) is arranged to convert electronic mon- 
ey transaction messages into corresponding ac- 
counting signals for changing the balance of an ac- 
count corresponding to said user. 

2. A system according to Claim 1 , characterized in 
that the system is arranged to send accounting sig- 
nals to the second telecommunications network to 
change the balance of the user's account with a sum 
corresponding to a received electronic money pay- 
ment request addressed to the user. 

3. A system according to Claim 1 or 2, characterized 
in that said electronic wallet means (124) is ar- 
ranged to send an electronic money payment into 
the first telecommunications network in response to 
a payment request. 

4. A system according to Claim 1 , 2, or 3, character- 
ized in that said electronic wallet means (1 24) is ar- 
ranged to collect more than one transaction of a us- 
er on an account internal to the system, before ef- 
fecting a transaction between the system and the 
user. 

5. A system according to Claim 1 , characterized in 
that the first telecommunications network is a TCP/ 
IP network. 

6. A system according to Claim 5, characterized in 
that the first telecommunications network is the In- 
ternet network. 

7. A system according to Claim 1, characterized in 
that the second telecommunications network is a 
conventional PSTN telephone network. 

8. A system according to Claim 1 , characterized in 

that the second telecommunications network is ar- 
ranged to support ISDN connections. 

9. A system according to Claim 1 , characterized in 
that the second telecommunications network is a 
cellular mobile telecommunications network. 

10. A system according to Claim 1, characterized in 



that the system further comprises transaction con- 
trol means in order to allow a user to confirm or de- 
cline transaction requests. 

5 11. A system according to Claim 1, characterized in 
that the system further comprises means for allow- 
ing a user to initiate an electronic payment transac- 
tion. 

io 12. A method for performing electronic money transac- 
tions, characterized in that the method comprises 
the steps of 

receiving a electronic money transaction re- 
's quest from a first telecommunications network 
addressed to a user in a second telecommuni- 
cations network, 

redirecting said request to an electronic wallet 
means instead of said user, and 
20 - transforming in said electronic wallet means the 
electronic transaction request to corresponding 
accounting signals for changing the balance of 
an account corresponding to said user. 

25 13. A method according to Claim 12, characterized in 
that the method additionally comprises the step of 
sending accounting signals to the second telecom- 
munications network to change the balance of the 
account of the user with a sum corresponding to the 

30 requested transaction, as a response to the re- 
quest. 

14. A method according to Claim 12, characterized in 
that the method additionally comprises the step of 

35 sending an electronic payment into the first tele- 
communications network in response to a payment 
request. 

15. A method according to Claim 12, characterized in 
40 that the method additionally comprises the step of 

checking, whether the user has authorized the 
transaction, and if the user has not authorized the 
transaction, sending a signal denying the transac- 
tion in response to the transaction request. 

45 

Patentanspruche 

1. Elektronisches Zahlungstransaktionssystem in ei- 
so nem Knoten zum Verbinden eines ersten Telekom- 
munikationsnetzes und eines zweiten Telekommu- 
nikationsnetzes, dadurch gekennzeichnet, daft das 
System eine Abfangvorrichtung fur elektronische 
Zahlungsvorgange (120) enthalt, und zwar zum 
55 Umleiten mindestens eines Teils von elektroni- 
schen Geldtransaktionsmeldungen, die von dem 
ersten Telekommunikationsnetz ankommen und an 
Teilnehmer in dem zweiten Telekommunikations- 
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netz adressiert sind, an eine elektronische Briefta- 
schenvorrichtung (124), und daB die elektronische 
Brieftaschenvorrichtung (124) zum Umsetzen elek- 
tronischer Geldtransaktionsmeldungen dient, und 
zwar in zugeordnete Abrechnungssignale zum An- s 
dern des Kontostands einse Kontos des Teilneh- 
mers. 

2. System nach Anspruch 1 , dadurch gekennzeichnet, 
daG das System Abrechnungssignale an das zweite 10 
Telekommunikationsnetz sendet, und zwar zum An- 
dern des Kontostands des Kontos des Teilnehmers 
gemaB einer Summe in Zuordnung zu der empfan- 
genen elektronischen Geldzahlanforderung, die an 
den Teilnehmer adressiert ist. 15 

3. System nach Anspruch 1 oder 2, dadurch gekenn- 
zeichnet, daB die elektronische Brieftaschenvor- 
richtung (124) zum Senden einer elektronischen 
Geldzahlung in das erste Telekommunikationsnetz 20 
in Ansprechen auf eine Zahlungsanforderung aus- 
gebildet ist. 

4. System nach Anspruch 1, 2 oder 3, dadurch ge- 
kennzeichnet, daB die elektronische Brieftaschen- 25 
vorrichtung (124) zum Sammeln von mehr als einer 
Transaktion eines Teilnehmers bei einem intern in 
dem System vorliegenden Konto ausgebildet ist, 

vor dem Durchfuhren einer Transaktion zwischen 
dem System und dem Teilnehmer. 30 

5. System nach Anspruch 1 , dadurch gekennzeichnet, 
daB das erste Telekommunikationsnetz ein TCP/IP 
Netz ist. 

35 

6. System nach Anspruch 5, dadurch gekennzeichnet, 
daB das erste Telekommunikationsnetz das Inter- 
net-Netzwerk ist. 

7. System nach Anspruch 1 , dadurch gekennzeichnet, 40 
daB das zweite Telekommunikationsnetz ein ubli- 
ches Fernsprechwahlnetz (PSTN) ist. 

8. System nach Anspruch 1 , dadurch gekennzeichnet, 
daB das zweite Telekommunikationsnetz zum Un- 4$ 
terstutzen von ISDN-Verbindungen ausgebildet ist. 

9. System nach Anspruch 1 , dadurch gekennzeichnet, 
daBdadurch gekennzeichnet, daB das zweite Tele- 
kommunikationsnetz ein zellulares Mobiltelekom- 50 
munikationsnetz ist. 

10. System nach Anspruch 1 , dadurch gekennzeichnet, 
daB das System femer eine Transaktionssteuervor- 
richtung enthalt, damit ein Teilnehmer Transakti- 55 
onsanforderungen bestatigen oder ablehnen kann. 

11. System nach Anspruch 1, dadurch gekennzeichnet, 



daB das System ferner eine Vorrichtung enthalt, die 
einem Teilnehmer das Initiieren einer elektroni- 
schen Zahlungstransaktion enmoglicht. 

12. Verfahren zum Durchfuhren von elektronischen 
Geldtransaktionen, dadurch gekennzeichnet, daB 
das Verfahren folgende Schritte enthalt: 

Empfangen einer elektronsichen Geldtransak- 
tionsanforderung von einem ersten Telekom- 
munikationsnetz adressiert an einen Teilneh- 
mer in einem zweiten Telekommunikations- 
netz, 

Umleiten der Anforderung an eine elektroni- 
sche Brieftaschenvorrichtung anstelle zu dem 
Teilnehmer, und 

Umsetzen der elektronischen Transaktionsan- 
forderung in der elektronischen Brieftaschen- 
vorrichtung in zugeordnete Abrechensignale 
zum Andern des Kontostands bei einem Konto 
fur den Teilnehmer. 

13. Verfahren .nach Anspruch 12, dadurch gekenn- 
zeichnet, daB das Verfahren zusatlich den Schritt 
zum Senden von Abrechnungssignalen an das 
zweite Telekommunikationsnetz enthalt, zum An- 
dern des Kontostands des Kontos des Teilnehmers 
mit einer Summe gemaB der angeforderten Trans- 
aktion als Antwort auf die Anforderung. 

14. Verfahren nach Anspruch 12, dadurch gekenn- 
zeichnet, daB das Verfahren zusatzlich den Schritt 
zum Senden einer elektronischen Zahlung an das 
erste Telekommunikationsnetz in Ansprechen auf 
eine Zahlungsanforderung enthalt. 

15. Verfahren nach Anspruch 12, dadurch gekenn- 
zeichnet, daB das Verfahren zusatzlich den Schritt 
zum Pruf en der Tatsache enthalt, ob der Teilnehmer 
fur die Transaktion authorisiert ist, und daB bei fur 
die Transaktion nicht authorisiertem Teilnehmer ein 
Signal zum Ablehnen der Transaktion in Anspre- 
chen auf die Transaktionsanforderung gesendet 
wird. 



Revendications 

1 . Systeme de transactions de paiement electronique 
dans un noeud joignant un premier reseau de tele- 
communications et un second reseau de telecom- 
munications, caracterise en ce que le systeme 
comprend un moyen d'interception de paiement 
electronique (120) qui est concu pour rediriger au 
moins une partie de messages de transaction de 
monnaie electronique arrivant a partir du premier 
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reseau de telecommunications et adress6s a des 
utilisateurs dans ie second reseau de telecommu- 
nications, vers une structure de porte-monnaie 
electronique (124), cette structure de porte-mon- 
naie electronique (1 24) etant concue pour convertir 
des messages de transaction de monnaie electro- 
nique en signaux de comptabilite correspondants, 
pour changer le solde d'un compte correspondant 
a cet utilisateur 

2. Systeme selon la revendication 1, caracterise en 
ce que le systeme est concu pour emettre des si- 
gnaux de comptabilite vers le second reseau de te- 
lecommunications, pour changer le solde du comp- 
te de I'utilisateur avec une somme correspondant a 
une demande de paiement par monnaie electroni- 
que recue, adressee a I'utilisateur. 

3. Systeme selon la revendication 1 ou la revendica- 
tion 2, caracterise en ce que la structure de porte- 
monnaie electronique (124) est concue pour Emet- 
tre un paiement par monnaie electronique vers le 
premier teseau de telecommunications en reponse 
a une demande de paiement. 

4. Systeme selon la revendication 1 , 2 ou 3, caracte- 
rise en ce que la structure de porte-monnaie Elec- 
tronique (124) est concue pour collector plus d'une 
transaction d'un utilisateur sur un compte interne au 
systeme, avant d'effectuer une transaction entre le 
systeme et I'utilisateur. 

5. Systeme selon la revendication 1 , caracterise en 
ce que le premier reseau de telecommunications 
est un reseau TCP/IP. 

6. Systeme selon la revendication 5, caracterise en 
ce que le premier reseau de telecommunications 
est le reseau internet. 

7. Systeme selon la revendication 1 , caracterise en 
ce que le second reseau de telecommunications est 
un reseau telephonique commute public classique. 

8. Systeme selon la revendication 1, caracterise en 
ceque le second reseau de telecommunications est 
congu pour permettre des connexions RNIS. 

9. Systeme selon la revendication 1 , caracterise en 
ce que le second reseau de telecommunications est 
un r6seau de telecommunications mobile cellulaire. 



11. Systeme selon la revendication 1, caracterise en 
ce que le systeme comprend en outre un moyen 
pour permettre a un utilisateur de declencher une 
transaction de paiement electronique. 

5 

12. Precede pour permettre des transactions de mon- 
naie electronique, caracterise en ce que le prece- 
de comprend les etapes suivantes : 

io - on recoit une demande de transaction de mon- 
naie electronique provenant d'un premier re- 
seau de telecommunications et adressee a un 
utilisateur dans un second reseau de telecom- 
munications, 

15 - on redirige cette demande vers une structure 
de porte-monnaie electronique, au lieu de I'uti- 
lisateur, et 

dans la structure de porte-monnaie electroni- 
que, on transforme (a demande de transaction 
20 electronique en signaux de comptabilite corres- 

pondants, pour changer le solde d'un compte 
correspondant a cet utilisateur. 

13. Precede selon la revendication 12, caracterise en 
25 ce que le precede comprend en outre I'etape qui 

consiste a emettre des signaux de comptabilite vers 
le second reseau de telecommunications, pour 
changer le solde du compte de I'utilisateur avec une 
somme correspondant a la transaction demandee, 
30 en reponse a la demande. 

14. Precede selon la revendication 12, caracterise en 
ce que le precede comprend en outre I'etape qui 
consiste a emettre un paiement electronique vers 

35 ie premier reseau de telecommunications en repon- 
se a une demande de paiement. 

15. Precede selon la revendication 12, caracterise en 
ce que le precede comprend en outre I'etape qui 

40 consiste a controler si I'utilisateur a autorise la tran- 
saction, et si I'utilisateur n'a pas autorise la transac- 
tion, a emettre un signal refusant la transaction en 
reponse a la demande de transaction. 

45 
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10. Systeme selon la revendication 1, caracterise en 
ce que le systeme comprend en outre un moyen de 
commande de transaction pour permettre a un uti- 55 
lisateur de confirmer ou de refuser des demandes 
de transaction. 
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